Publication and Alerts Security

The security model governing content produced by the Publication engine is designed to COMPREHENSIVELY make the delivery of content both simple to implement and secure.

The content access and security for publications and alerts is driven from multiple levels:

• Content Destination – determines where content can be accessed. Different “venues” have different levels of access security for publications and alerts.
• Viewer – for each destination, the “viewer” provides optional control over the security of content through either role or data security or both.
• Rendering – when content is rendered, the mode in which it is run can add further control over the content that is exposed to each recipient.

Each level is described below.

 

Content Destination

When a Publication template is scheduled to run, designers are required to choose from which end points the publication will be available (green boxes in diagram above):

• Portal Viewer: the content will be directly accessible from inside the main BI Office application in both the OPEN and FEEDS panels; it will be accessible from the Basic UI in both the main client and the mobile/HTML5 client from the PUBLICATIONS panel.
• API: the content can be enumerated and listed using the web service API’s for publication into 3rd party components and tools.
• Email: the content can be delivered as attachments or links in emails to recipients. Since the link merely forces the user to return to the portal to retrieve their content, the real focus here is on email attachments.

Security Implications

• The Portal option requires the end user to login and authenticate access to the BI Office platform, and it therefore provides the most secure delivery format.
• The API option, only requires access via code through administrative privileges. However, the API’s do provide a mechanism to filter content based on the target end user’s content access.

• The Email with attachment option provides no deployment security, as the end user merely receives the content "as is" directly (magenta mail icon in the image). However, email can utilize the rendering security described below. As mentioned, emails with links provide the same outcome as the portal option.

IMPORTANT: As such, both Portal and API destinations are controlled interfaces, and provide the ability to deliver the next tiers of security: Viewer Security and then in turn Data Security.

NOTE: Different publication destinations are available based on the application license for a given implementation.

Viewer and API Security

When a Publication template is scheduled to run, designers are required to choose whether “viewer” security will be applied to the batch of rendered publications. The viewer security is driven from two distinct layers: Role Security and Data Security. The role security precedes the data security layer from the end user’s perspective (the two black ellipses in the diagram above).

Role Security

Like all other reporting artifacts in the BI Office suite, designers can indicate which security roles will have access to published reports and alerts. Designers can assign which roles will be able to VIEW rendered content by giving each role the ability to “VIEW” a Publication template or alert. This can be done from:

• The backstage OPEN panel for the template.

• Inside the Schedule Interface for the given publication or alert template.

View vs Read/Write

All BI Office reports can have role access set to either “Read” or “Write”. This includes Publications. These switches will allow the affected users to open the underlying content and/or edit and save the content.

If a user does not have READ access to content, they will NOT be able to see the reporting content in the file manager tree. The same logic applies to Publication content. However, this does not affect whether they will be able to see RENDERED reporting and alerts produced from the templates. This is governed by the “View” setting for each role on Publication content.

Effect of the View Switch

Without the ability to “view” rendered content for a given template, a user will NOT be shown ANY rendered content produced from a given template. This step, therefore, precludes the effects of the data security layer which is explained next.

IMPORTANT: Role view switches work on an OPT-IN methodology. The default is that users will NOT see content.

Data Security

When Publication templates are created they are usually designed with “slicers” that allow designers to run variations of the template with different SLICES of data from the underlying data models. For instance, a financial report might be built with a time slicer, so that the report can be produced for different time periods. The slicer, in effect, filters the underlying queries in a report.

When slicers are added to a template, designers can optionally decide to secure the content using the slicer’s value in a given rendered publication or alert. This provides a simple mechanism to delineate report access by ensuring only those end users who can ordinarily see a given time slice value in the data model can see the matching slice-rendered publication or alert.

Example:

A salesman review template is designed in Publications to produce a report for each salesman in the company showing their performance in the current period. A generic template is written for ANY salesman and a slicer is attached with a list of the salesman in the company from the salesman hierarchy. When the template is launched, it will run the template rendering queries filtering the content and results to the currently selected salesman from the slice.

The rendered content is made viewable to all the users in the “salesman” role. The designer also elects to apply data security to the rendered content using the salesman slicer. In turn, when ANY salesman in the role accesses the rendered content in the Portal Viewer or API functions, they will be able to see only those reports where their own data access allows them to see the element used to slice a given report.

So when the report is run for salesman “John Smith”, a report filtered to results for John Smith is produced. Anyone who could see “John Smith” in the underlying data model will also see this report – otherwise they will not see it in the listing! The result, is that the rendered content is secured and made accessible only to those with the normal rights to view John Smith’s data.

IMPORTANT: Data Security switches work on an OPT-OUT methodology. The default is that users will see all content that their role level view security allows them to see (unless they are further restricted by the data security layer).

Rendering Security

A further layer of security can be applied to each report as it is rendered (purple object in the diagram above). Using the slicers defined in the template, designers can elect to use an attribute property from the hierarchy used to define the slicer to enact rendering security.

The property needs to hold the account name of a user that will be used to run the report as if the user ran the report manually himself. By “impersonating” the user, the rendered reports can be fully secured not only by a given slice filter, but also across any other data security logic embedded into the data model that is not only handled by the slice filtering alone.

This security layer runs when a report is rendered and can be applied to all destination types. Used in combination with the data security layer previously, rendering security provides the most robust way of delivering secured content to end users when either:

• The reports are predicated on complex security models and data filtering that cuts across a single hierarchy.
• The data model security settings are not exclusively driven through one of the attached slicers.

NOTE: Rendering security is only available to users with a Professional License and can be accessed in the Distribution Panel of the Schedule Interface.

Example (continued from the example above):

John Smith, as a user, should not be able to see and analyze certain products in the Product hierarchy. Without the rendering security (“impersonation”), the rendered report will show all data by all viewable products filtered for John Smith (assuming this is how the query is structured).

However, if this report was given to John Smith, he would potentially see products he shouldn’t be able to see. If instead the report was RUN AS John Smith, it would be filtered for him via the slicer and have the products automatically removed from the queries that he would not ordinarily see.

IMPORTANT: Rendering Security switches work on an OPT-OUT methodology. The default is that users will see all content that their role level view security allows them to see unless they are further restricted by the data security layer.